银行移动产品从团队敏捷走向产品敏捷

中国银行业的数字化转型刚刚拉开帷幕，移动产品成为了中国银行业的新战场。为在新战场占有一席之地，各家银行开始纷纷尝试自己移动产品的敏捷转型，更有甚者开始重新组建IT团队，用敏捷的方式重做原有的手机银行产品。

但这些转型往往在6-12个月后显示出明显的疲态。基本的实践都已经导入了，团队似乎已经“敏捷”了，但产品的响应速度并没有变快多少（想法的提出到上线的时长），产品的线上月活也没有显著的提升。那么敏捷转型到此就结束了吗，敏捷转型的下一步我们又该做什么？这篇文章作者将以多个实际案例出发，为大家揭晓银行业的移动产品如何从团队敏捷走向真正的产品敏捷。

团队敏捷是必要的，它是产品敏捷的必经之路

银行移动产品的敏捷转型很难一蹴而就，团队已经适应了“慢节奏”，习惯了阶段式的开发方式，敏捷的导入，无疑是一场变革。大规模的灌入标准化实践，最后的结果只会是“有形无实”，就像办公室中贴满五颜六色便签纸的白板，最后都沦为装饰品（数周也不更新）。

团队敏捷作为敏捷转型的第一步，以了解团队、分析痛点为前提，定制化的导入实践，让团队从传统向敏捷的开始转变。转型团队敏捷聚焦IT研发团队内部，包含产品、研发、测试人员，目标是：

• 打造出一支敏捷迭代运作的IT研发团队

• 建立团队级的敏捷流程及工程方法

• 以及初步形成内部改进的种子力量

以50人的手机银行团队为例（4个全功能团队），团队敏捷从开始转型到稳定运作会持续4-8个月的时间。具体的转型过程就不在这里多做论述了。如果您的团队已经满足了以上的3个目标，那么恭喜您，您的团队已经迈出了敏捷转型的第一步。

产品敏捷的目标

“创业像开车，而不是发射火箭” ——埃里克 莱斯（精益创业的作者） 

做产品也是一样。环境变化太快，产品很难像发射火箭一样，经过长时间缜密准备再发射验证。产品要像开车一样，有一个前进的方向，之后在行驶过程中根据外界的变化快速做出调整并验证，产品敏捷的目标也将聚焦于此。

• 帮助产品构建像“开车”一样，可以根据外界变化做出快速响应的能力；

• 在产品演进的过程中，帮助产品选择相对正确的“行驶”方向，帮助产品实现“弯道超车”。

很显然，团队敏捷，主要聚焦于研发团队内部的改进，对以上两点的影响并不大，更像是敏捷的萌芽和生长阶段。产品敏捷是以上述两点为目标，端到端（想法的产生到功能的上线）的分析及改进整个产品的实施过程，像是敏捷的开花结果。

走向产品敏捷的三个关键点

一、构建产品快速响应的能力

产品TTM（Time To Market）的长短体现了产品的响应能力的高低。以TTM的持续缩短为目标，是整体转型的关注点从“资源效率”到“流动效率”的改变，分析“流动单元”在产品端到端的实施过程中的流动情况，找到瓶颈点并加以改进，来持续提升“流动效率”，是转型的关键，主要分为3个步骤：

• 分析并定义产品端到端的实施过程；

• TTM的相关数据采集；

• 基于VSM的持续改进。

步骤1：分析并定义产品端到端的实施过程

团队敏捷中我们聚焦IT研发团队内部的迭代运作，在产品敏捷，我们需要以版本为维度，以需求为“流动单元”去梳理并定义端到端的研发过程，关键点是将产品版本与研发迭代融合。

如下图，以某金融产品按月发版，研发双周迭代为例。需求分为Epic，Story两个层级，Epic为解决一个用户问题，Story为实现Epic的功能拆分。在版本迭代，我们关注的是Epic的流动（一个版本会包含多个Epic），从想法的提出，到最终的上线。在团队迭代来研发产品，我们关注于Story的流动，从Sprint Backlog的确认，到功能的持续交付（SIT环境）。端到端的实施过程覆盖了所有活动、产出件及流程流转，每一项都有自己独特的意义，每个产品的运作方式都有可能不同，重点是加强各个角色间的协作，使得团队适应该种运作方式，可以稳定的运作。

（某金融产品 产品端到端实施过程）

步骤2：TTM相关数据的采集

数据采集的前提实施过程梳理清晰且团队稳定运作。根据实施过程，我们可以清晰的得出Epic和Story的两条价值流，如下图。TTM是每个Epic从概念到上线的平均时间（如果Epic都是运营类的小需求，建议做合并成一个Epic）。当然Story的大小我们是可控的，Story的产生到集成测试完成的时间我们也要关注。

（某金融产品 Epic、Story的价值流）

数据不是通过WorkShop的问问答答就能得出的，需要借助电子工具的辅助，做准确的分析。首先作者对于电子工具的态度是：工具是辅助运作，而不能影响运作，不能出现由于电子工具的限制而改变运作结构。电子工具的目的是便于过程管理及可视化。

作者推荐的工具是Jira，Jira的优势在于可以通过配置实现高度的定制化，以及开放API数据接口（商用版）。作者建议抛开Jira中大部分的预定义好的模板及元素，根据现有的运作方式，做深度的定制（例如Story元素的重新定制）。从Jira中“问题属性”、“字段”、“界面”、“工作流”、“权限”等的自定义，到Jira Agile中的“看板”，“阶段”，“移动规则”等自定义。由于是相对于底层的定制，所以配置起来比较复杂，这里要保持开放的心态。

如下图，根据运作方式，在关键节点引入Jira做管理，并且根据运作方式，确定Jira的使用规则。

（某金融产品 配合运作方式的Jira使用）

在上线了2-3个版本后，我们就可以尝试做数据的采集及分析，Jira提供了方便的API接口供我们提取数据，要注意数据清洗及公式的配置，最后得出每个版本的TTM时长。

步骤3：基于VSM的持续改进

我们使用的实践是精益中的VSM（Value Stream Mapping）价值流图，来做持续的改进。通过Jira中的数据，建立Epic和Story的价值流图。以Story为例，如下图，数字为Story在该阶段的平均停留时长（天），按照迭代做分组。分析数据找到可能的问题点，很明显前4个迭代“待联调”和“测试中”的用时很长，之后去做该阶段的原因分析并尝试改进，再分析新的数据（第5个迭代的数据提升），以做到团队的持续改进。

当然了这里面的问题点是多样的，组织、需求、管理、技术等因素都可能成为问题的原因，这里的重点是找到核心问题，拿着数据证明去尝试解决，最终也可通过VSM也来体现我们的转型成果，这也是真实的量化的数据。

（某金融产品 前5个迭代，Story的VSM）

电子Dashboard。持续的Excel取数很难做到实时。尝试做电子Dashboard，做到价值流实时可视化，便于信息的透明化及持续改进，为提高产品的响应力打下坚实的基础，详见下图。

（某金融产品 价值流Dashboard）

到此阶段，您的团队已经有一套端到端的稳定运作方式及电子管理平台，可视化的VSM来体现问题点及成果展示。剩下的就是大胆去做瓶颈的原因分析及改进，来持续的提升产品的响应能力。

二、帮助产品实现“弯道超车”

金融科技企业对中国银行业的冲击是巨大的。多家传统银行直面差距，定义自己的移动产品策略是“追赶”，产品经理的惯性思维，“XXX有这项功能，做了这项优化，我们的产品要把它加上”。当然了如果落后，追赶固然没错，但在追赶的过程中我们也要制定赶超的策略。

金融需求无处不在，衣食住行娱每个细分场景都有金融需求出现，对于传统银行，信誉，数据、网点、存量用户等都是自有的优势。那么结合用户的需求与自身的优势实现金融产品创新，才是“弯道超车”的关键。

利用设计思维的方法来获取、定义及实现用户的需求。扭转业务、产品、研发等角色的本位思维，从提出需求走向了解用户痛点，从实现需求走向为用户创造价值。

（设计思维的双钻模型）

建立产品内部的创新机制，抛开传统银行自身的限制，鼓励全员创新。如下图，从一个创新想法，到MVP的制作验证，最快只需要3周的时间。立项通过的想法进行2-3个月的孵化验证，最终有望形成新的商业产品。过程中给予创新者创新教练、团队资源的专项支持，内部创新的同时也在培养团队产品思维，提升团队的产品能力。

（某银行的内部的创新机制）

三、培养内部教练队伍

这个是敏捷转型的基础，需要进行管理、技术、产品、创新等内部教练的梯队建设。组织中缺少的是经验积累及专有人才，而不是流程规范。之后作者会以专文来讲述企业内部教练的体系建设。

总结

在移动金融产品的新战场上，银行的移动产品需要从“发芽生长”的团队敏捷，走向“开花结果”的产品敏捷。

三个关键点助力产品迈向产品敏捷：

1. 通过产品开发过程端到端的梳理与定义，电子工具的引入，基于VSM的持续改进，来持续缩短产品的TTM，构建产品快速响应的能力；

2. 使用设计思维打造产品，并建立产品内部的创新机制，来实现金融创新，帮助产品实现“弯道超车”；

3. 建立企业内部的教练体系，注重人才培养及积累经验，来推动敏捷的发展，促使产品持续进步。

最后，希望中国银行企业把如今市场中的不确定性，看做是产品的新机遇。对于这种新机遇的驾驭的能力，将成为产品优胜劣汰的关键。

---

- 相关阅读 -

本文版权属ThoughtWorks公司所有，如需转载请在后台留言联系。